@twilliability @JulianOliver It's all about Internet trust, and how that is realized in terms of cryptography. The current system lets bots and crawlers discover new sites just by looking at CT Logs.
Every time a new web site with a fresh X.509 certificate spins up, as required for TLS security in HTTPS, the CT logs are updated. Nowhere to hide -- the Common Name (CN) field in the cert will disclose the site's address.
This can be mitigated to some extent if you're willing to push certificates to end users of a web site in other ways. DANE pushes some of that to the Domain Name System, relying on DNSSEC as an alternative trust anchor; the TLSA records in DNS which DANE uses specify what to trust, and how to trust.
This has been broadly criticised by many cybersecurity professionals as leading the user and site alike to trust nation state actors due to its DNSSEC dependency, however, that only applies to the ability to sign the records thus served.
The site decides which certificates to present. They need not be logged to CT and can be self-signed; in practice, they often are. It's a trade-off.
Ultimately end-users are railroaded into the WebPKI trust model as it exists today, mostly because of control of the web browser space.
Although browser extensions from NIC.CZ for example were published in the early 2010s showing that Chromium and Firefox derived browsers alike could use DANE for web site HTTPS trust chains, they are badly bitrotted and unusable now.